The transfer of AV data flows between a data source and a data sink is the subject of a multitude of investigations and standardization efforts in the industry. Exemplary networking systems having been specified have become known by the abbreviations HAVi (Home Audio/Video interoperability) and UPnP (Universal Plug and Play). The transfer of AV data flows has been particularly taken into account in these network systems since the HAVi system has been primarily developed for this case of application, and with regard to the UPnP system, a working group of the UPnP forum developed a UPnP AV specification which is based on the general UPnP specification and expands it. The designation of this specification is UPnP AV Architecture: 0.83 of 12 Jun. 2002.
The mentioned specifications support the detection of AV devices, setting up AV connections, finding AV contents, operating the data source and data sink device, replay of selected AV contents in the mode of normal replay and in trick mode replay, etc.
Trick mode replay shows a behavior which is problematic. For that, the data transfer between two devices A and B in the network will be considered in detail. It is assumed that device A is a data source—such as, e.g. a digital video recorder which is hard disk based and has AV contents stored. Device B should serve as data sink, e.g. as a display device. Both devices are provided with a communication interface for data exchange as well as for the exchange of control commands. In data transfer (which can be done e.g. in TCP/IP based networks via HTTP or via RTP), the data must, as a rule, go through different buffer memories. The transfer network itself can also be considered a memory in this sense because even this transfer can result in delays on the net.
The replay of AV contents is relatively simple in case of normal replay (thus with simple replay speed). Via the communication interface, the devices are informed which content is to be sent where and, respectively, what they are to receive; and then, replay can start. However, it will be problematic with the so-called trick modes (fast forward, fast reverse, slow motion, still image). As an example, a case will be considered where the AV system is in normal replay mode and will then be switched, without pause, to a higher forward speed, e.g. triple search function.
It is here assumed that the device A supports so-called “server side” trick modes, i.e. that the source will modify the data flow such that the receiver will receive a valid data flow from which the images not to be shown have already been removed. For that, a corresponding trick mode module is looped into the data path in device A.
The data generated by this module must now run through the memories on the transfer path, e.g. a sender memory, a receiver memory, and a buffer memory for the data decoder. That means the data still existing in these memories at the time of switching must actually still be decoded by the decoder in device B before the trick mode specific data can be decoded.
This characteristic is problematic, and the user perceives it as inertia of the system, i.e. after the user informed the system of the intention to change to a forward function, replay will still continue as before and will actually change to fast forward only after a certain period of time. The amount of this time delay essentially depends on the size of the available memories.